Thread: warning: function returns address of local variable [-Wreturn-local-addr]

Hi,
I have a question if there is a way for solving this problem in C.

Given an interface like this:

char * doublestring(char *str);

An implementation requirement that states:

Given an input string "Test " the function doublestring shall return "Test Test" and using only a string that exactly matches the required size (so input string x 2 + 1 as there is a space)and the constraint of not using helper functions (I assume malloc...) is there a way to implement this?

The problem obviously is, that when creating an array in the function like outputString[lengthInput*2+1] it triggers the warning "warning: function returns address of local variable" as the array is removed from stack. When using a global array I cannot make it dynamic as the interface without prior counting the chars in the string until '\0'.

One could like use the argument pointer, but then I am only sure that the amount of size required for the input string (which is smaller than the outputstring) is reserved...

Also I cannot make the array static, as the size can change with every call...

So a dirty "solution" would be

Code:

#include <stdio.h>

#undef DEBUG


char *strdouble(char *str);


int main()
{


    char *str = strdouble("This is a test sentence!");
    printf ("%s", str);
    
    char *str2 = strdouble("");
    printf ("%s", str2);
    
    return 0;
}


char *strdouble(char *str)
{
    int lenOfInput = 0U;
    
    // Find out length. String per 
    // defintion terminated by '\0'
    while(str[lenOfInput] != '\0' ) {
        ++lenOfInput;
    }
    
    // Now create the outputstring
    int lenOfOutput = lenOfInput * 2 + 1;
    int strTwoOffset =  lenOfInput + 1;
    char outputString[lenOfOutput];
    
    #ifdef DEBUG
    printf ("Output %d \n", lenOfOutput);
    printf ("Input %d \n", lenOfInput);
    #endif 
    
    for (int iterator = 0; iterator < lenOfInput; iterator++) {
        outputString[iterator] = str[iterator];
        outputString[iterator + strTwoOffset] = str[iterator];
    }
        
    outputString[lenOfInput] = 0x20;
    outputString[lenOfOutput] = '\0';
    
    str = outputString;
    
    
    return str;
    
}

But that cant be the way to go...

I really didn't find anything by googling to solve this issue, other than malloc or making things static (which I cant do here).

Is this actually doable?

BR

Originally Posted by laserlight

A correct approach would be to use malloc (or realloc, or lower level functionality that would have been used to implement malloc). Why is there a requirement of "no helper functions" that includes no malloc?

The approach of requiring the caller to provide the input string in an array sized for the output string can be correct, but would be error-prone. I would recommend changing the interface if that is preferred as it would provide flexibility to the caller (can opt for dynamic memory allocation, or not): have an input string, and output pointer to string, and a size parameter for the output array size (or maximum string length, if you prefer).


You're still returning the address of a non-static local variable, so there's undefined behaviour once an attempt is made to use the doubled string.

Hi laserlight,

Thanks for your answer. It's an example that states to implement the function without helper functions. I am not sure if that was referring to string manipulation only or also memory management.

I agree if thats really the case the best way would be to change the interface, but here its given. I am going for the malloc solution as i assume my assumation are wrong :-) (lots of assumes haha).

BR

Originally Posted by john.c

You say you "assume" you can't use malloc. Since that is impossible, I assume that you can.
Even your "dirty" (read "totally incorrect") version assumes VLA's exist, but that is only guaranteed in C99, not prior to that and not in C11, where they are optional.

Thanks for your reply. Ass mentioned in my previous reply I guess my assumation are wrong. But it helped me understand the issue a little better.